-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Solana] Allowlist on token pool #564
base: main
Are you sure you want to change the base?
Conversation
old_authority, | ||
new_authority | ||
}); | ||
Ok(()) | ||
} | ||
|
||
// set_router changes the router program ID. This is used to derive the list | ||
// of valid mint/release callers (offramps). | ||
pub fn set_router(ctx: Context<SetConfig>, new_router: Pubkey) -> Result<()> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could this method be cyclic in some way? Is that a concern?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what you mean exactly about cyclic
in this case 🤔
This method may only be invoked by the pool owner, not the router. Then, the router address here is used just to later check if the calling offramp is a valid one or not.
I've checked a bit and we already have another field in the pool though called ramp_authority
that has the onramp address... And that's always the same as the router address, so we could just reuse it (even though in EVM they are separate concepts, here they are pretty much the same thing....)
can we add a test (if not present) of removing an offramp and then checking for it? |
f254857
to
cd69649
Compare
|
Similar to the approach taken for the example receiver.
TokenOfframp
takes a whitelisted offramp as signer, butTokenOnramp
continues to use the router as signer, as before.